3 Business Procedures 3.1 Overview There are a number of business procedures that must be followed when running the Interface. This section explains the business procedures. 3.2 Explanation of the Procedures The correct business procedures must be followed to ensure the correct processing of movements passed through the Interface. These procedures include defining both the source database (iBroker) and the M2 target database (RawInput); the correct set-up of end-users within m2CRM and the correct operation of the components of the Interface. 3.3 Order of Operation of the Interface components The interface components must be run in sequence for the correct operation of the process. Follow these steps to correctly operate the Interface components when adding new clients to M2. " Set up the clients within the source in-house system to ready the movements that apply to them for transfer. " Set up the clients within the M2 system and create their initial holding positions. " Set up Extractor and then run the Extractor process selecting the Client History Load option. " Run the Adaptor. " Run Submission and then if it has not already been started, start Release. Follow these steps to correctly operate the Interface components when undertaking a daily Movements run. " Run the Extractor process using the Daily Movements option. " Run the Adaptor. " Run Submission and then if it has not already been started, start Release. 3.3.1 Extractor Daily Movement extracts don't really need any special knowledge of the system except for the timing of the take-on of new clients into M2. It is best not to run the daily movements extract until new clients are properly set up as the daily movements extract may attempt to adjust positions which are not properly set-up. To set up a New Client in M2: Step 1. - First add the new Client using m2CRM. This involves filling out all the normal fields required plus selecting (as a minimum) the Account which synchronises with the iBroker adaptor (this is ISS-TRD - ISS Trading in the case of ISS) and entering the same client number in iBroker in the 'link reference' field for the ISS-TRD account for the new client. Step 2. - Next, set the M2 Interest code field on the client in iBroker (in the case of ISS add the code '5' to the Interest codes for the client) Interest Codes: There is an optional setting in iBroker called Interest Codes which allow 1 or more 'Interest Codes' to be allocated to an iBroker client. The number 5 has been allocated to m2. The key use of the nominated Interest code is that it allows the Extractor to select interface data from only those clients tagged for 'M2 Portfolio'. Step 3. - Identify how far back you wish to keep history on M2 for this client (ie. a history 'start date' ) and collect the 'cost base' figures and quantities of all securities holdings that existed at the historical 'start date' from the legacy systems. Manually load these opening balances using m2CRM Asset In/Out (i.e. you are only loading the assets themselves not updating the cash balance of the iBroker trading account at this point) and date them as at the appropriate 'cost base' date. There are two options available for 'cost base' dating - they can be the original date the asset was purchased using the original purchase price or a 'valuation' date say as at the start of the last financial year - the important point that must be noted is that it will be necessary to also manually apply any Corporate Actions that have occurred since the selected 'cost base' date. Step 4. - Identify the starting date from when you wish to load movements automatically from iBroker over the Interface. This is achieved by reviewing transactions for the client in iBroker. In some cases it will be OK to load all history (if iBroker has only been used recently) in other cases it will be necessary to select a start date to tie in with the 'cost base' date selected for the client. In the case where there is a time gap between the 'cost base' date selected and the first transactions available for automatic load via the interface (as will be the case at iBroker) it will be necessary to manually load (using m2CRM) any other securities bought or sold over the intervening period. It is recommended that these movements are loaded as AssetIn(Buys) or AssetOut(Sells) so no cash effect is loaded with them. Step 5. - Load up the 'cash' balance of the Trading account. Retrieve the Trading Account cash balance as at the EOD of the day prior to the selected history 'start date' (Step 3) and load the Trading Account opening 'cash' balance as either a Deposit (account in credit) or a Withdrawal (account over-drawn) using m2CRM. Step 6. - Load up history from the selected 'start date'. Run the Extractor, select Client History Load, enter the client number as used in iBroker, enter the selected Date Range From and Date Range To and then press the Extract Now button. Run the Adaptor and then Release the movements if necessary in the Interfaces section of m2Controller. This should bring the m2 Holdings up to date except maybe for some Corporate Actions) and the 'cash' balance of the Trading Account should be synchronised with iBroker for that client and will then stay in step with the Daily Movements Extract. Step 7. - Final adjustments may be necessary: (a) to bring holdings into line (with say CHESS) for any corporate actions which may have adjusted holding quantities (Splits and Consolidations). These need to be manually checked and updated using the appropriate movements in m2CRM. (b) to reclassify any cash movements which were in fact income (Divs, Int or Distributions) as these are not separately identifiable at this stage via the iBroker Interface. It may mean that some income cash entries loaded automatically as Deposits or Misc Receipts will need to be deleted and re-entered as Divs etc. in order to properly record them as Income. 3.3.2 Adaptor There are no business procedures associated with the Adaptor process. However, for now you will need to review all movements and manually submit them one at a time. 3.3.3 Release There are no business procedures associated with the Release process. 3.3.4 Submission There are no business procedures associated with the Submission process. 3.3.5 Update There are no business procedures associated with the Update process.